Sandboxing requests for web services

ABSTRACT

A web service request is received, and a stored performance metric value, generated for other web service requests of the same type, is compared to a threshold value. If the stored performance metric value meets the threshold value, then the received web service request is routed to a sandboxed instance of the web service for execution. If the stored performance metric value does not meet the threshold value then the received web service request is routed to a default web service instance for execution. In either case, the performance metric is monitored during execution of the received web service request, and the stored performance metric value is updated based upon the monitored performance metric generated for the received web service request.

BACKGROUND

Computing systems are currently in wide use. Some computing systems aredeployed in a remote server environment where they host services whichcan be accessed by various different client computing systems. Theclient computing systems or other computing systems make requests to theservices that are hosted at the remote server environment (e.g., in thecloud). For instance, services may be hosted in a data center, or inanother remote server environment.

It is not uncommon, in such computing systems, for computing systemresources to be assigned to one or more different instances of theservice being hosted. For example, an instance of a service being hostedmay be assigned a certain level of central processing unit (CPU)resources, or physical processors, it may be assigned certain memoryresources (e.g., blocks of virtual or physical memory or a certainamount of memory) or other computing system resources.

In rendering the service, the computing system often responds to a verylarge number of requests from a variety of different applications orclients. It may be that one or more of the requests can degrade thequality of service at the expense of other requests. For instance, itmay be that an application or user is making an unusually high volume ornumber of requests to the hosted service. Similarly, a request mayconsume an inordinate amount of computing system resources (such as CPUresources, memory resources, etc.). When these requests are beingserviced, they can affect the performance of the service in respondingto other requests that do not exhibit these characteristics. When moreof these types of requests are received (the type that deleteriouslyaffect the performance of the service), this can cause an overall dropin reliability that, over time, can even cause the web service todeteriorate progressively. Thus, eventually, these types of requests(that consume an inordinately large amount of resources, or that arereceived at an inordinately high volume, triggering a buggy code path,etc.) can affect the other requests and can even deleteriously affectthe performance of the service overall.

The discussion above is merely provided for general backgroundinformation and is not intended to be used as an aid in determining thescope of the claimed subject matter.

SUMMARY

A web service request is received, and a stored performance metricvalue, generated for other web service requests of the same type, iscompared to a threshold value. If the stored performance metric valuemeets the threshold value, then the received web service request isrouted to a sandboxed instance of the web service for execution. If thestored performance metric value does not meet the threshold value, thenthe received web service request is routed to a default web serviceinstance for execution. In either case, the performance metric ismonitored during execution of the received web service request, and thestored performance metric value is updated based upon the monitoredperformance metric generated for the received web service request.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter. The claimed subject matter is not limited to implementationsthat solve any or all disadvantages noted in the background.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of one example of a computing systemarchitecture.

FIG. 2 is a block diagram showing one example of the computing systemarchitecture illustrated in FIG. 1, in more detail.

FIGS. 3A and 3B (collectively referred to herein as FIG. 3) show a flowdiagram illustrating one example of the operation of the architectureillustrated in FIGS. 1 and 2.

FIG. 4 is a block diagram showing one example of the computing systemarchitecture illustrated in FIGS. 1 and 2, deployed in a cloud computingarchitecture.

FIG. 5 is a block diagram showing one example of a computing environmentthat can be used in the architectures shown in the previous figures.

DETAILED DESCRIPTION

FIG. 1 is a block diagram of one example of a computing systemarchitecture 100. Architecture 100 shows computing system 102 connectedto a plurality of different client computing systems 104-106 overnetwork 108. Computing system 102 illustratively hosts a web servicethat can be accessed by client computing systems 102-106 over network108. Therefore, in one example, network 108 is a wide area network, alocal area network, a cellular communication network, a near fieldcommunication network, or any of a wide variety of other networks orcombinations of networks.

FIG. 1 also shows that, in one example, client computing systems 104-106generate user interfaces 110-112, respectively, for interaction by users114-116. Users 114-116 illustratively interact with user interfaces110-112 in order to control and manipulate client computing systems104-106, respectively, and in order to interact with the service hostedby computing systems 102. In doing so, client computing systems 104-106can generate web service requests (based on user inputs from users114-116, or otherwise), and submit those requests to computing system102. The web service requests are illustratively requests that are to beexecuted by the hosted web service.

In the example shown in FIG. 1, computing system 102 illustrativelyincludes request filter and router system 118, request-based performancemetric and threshold data store 120 (which can include a database,memory, etc.), default web service instance 122, sandboxed web serviceinstance 124, and it can include a wide variety of other computingsystem functionality 126. In one example, request filter and routersystem 118 groups the requests it receives from client computing systems104-106 into groups based on a variety of different grouping criteriaand grouping rules. The grouping criteria can include such things as thesource of the request (e.g., the application ID, the user ID, etc.), thetype of request (e.g., the type of operation to be executed in executingthe request), the requested resource, among other things. Grouping rulesspecify that requests that have certain criteria or combinations ofcriteria in common, are to be grouped into groups. Then, performancecriteria corresponding to the requests in the various groups aremonitored by system 118. The performance criteria can include a widevariety of criteria, such as request-response latency, the volume orfrequency of this type of request, the amount of CPU or memory usageconsumed by this type of request, among other criteria. The values forthe different performance metrics, corresponding to each group ofrequests, is stored in data store 120 and updated as different requests,corresponding to each given group, are received and executed oncomputing system 102. Thresholds for the different criteria are alsoreceived (or generated) and stored in request-based performance criteriaand threshold data store 120.

Once the rules for the groups of requests are established, and theperformance metric values for a number of different samples of eachgroup of requests have been monitored and stored in data store 120, andonce the threshold values are stored, then, when a new request isreceived, request filter and router system 118 accesses the groupingrules and identifies the particular group that it belongs to (if any)and accesses the performance metrics and thresholds for that group. Itcompares the performance metric values for the group to thecorresponding threshold values to determine whether this group ofrequests is inordinately, deleteriously affecting the performance of theservice. If so, it can send the request to the sandboxed web serviceinstance 124, where its execution will not affect (in terms ofperformance) the web service request being executed (on different data)in default web service instance 122.

In one example, the comparison of the performance metric values to thethreshold values can indicate an inordinate deleterious affect if theperformance metric values meet, or exceed, the threshold values. Forinstance, it may be that the detected CPU usage when executing webservice requests in this group normally exceeds a threshold value of CPUusage set for requests in this group. The same may be true of memoryusage and/or latency or other performance metrics. These are onlyexamples.

Also, in one example, the computing system resources assigned to defaultweb service instance 122 are much larger than the computing systemresources assigned to sandboxed web service instance 124. For instance,the CPU resources, the memory resources, and the other computing systemresources assigned to sandboxed web service instance 124 may be 5% or10% of those assigned to default web service instance 122. Regardless ofhow large the amount of resources assigned to instance 124, relative tothose assigned to instance 122, it will be appreciated that theresources assigned to sandboxed web service instance 124 are separatedfrom those assigned to default web service instance 122 so that, when aservice request is executed in sandboxed web service instance 124, itsexecution will not affect the performance of default web serviceinstance 122 in the execution of any other web service requests (onother data). By way of example, if the web service request beingexecuted in sandboxed web service instance 124 is consuming a largeamount of CPU resources, so that it has a relatively highrequest-response latency, this will not affect the request-responselatency of the web service requests being executed at default webservice instance 122. This is just one example of how the resources areseparated.

FIG. 2 is a block diagram showing one example of the computing systemarchitecture 100, illustrated in FIG. 1, in more detail. Some of theitems shown in FIG. 2 are similar to those shown in FIG. 1, and they aresimilarly, numbered.

Client systems 104-106 can be similar, or different. For purposes of thepresent description, it will be assumed that they are similar, so thatonly a more detailed description of client computing system 104 isprovided. Client computing system 104 illustratively includes one ormore processors or servers 128, data store 130, service accessing logic132, user interface logic 134, and it can include a wide variety ofother items 136. User interface logic 134 illustratively generates userinterfaces 110 and detects user interaction with interfaces 110. It canprovide an indication of these interactions to other items in clientcomputing system 104, or elsewhere. Service accessing logic 132illustratively includes functionality used when client computing system104 interacts with the service hosted by computing system 102. It can bea client component of that service, or another set of logic that is usedto interact with the service.

FIG. 2 also shows that both default web service instance 122 andsandboxed web service instance 124 are illustratively assignedprocessing resources 138, 140, memory resources 142, 144, and they canbe assigned a wide variety of other computing system resources 146, 148that are used in executing service requests received form system 118.Default web service instance 122 includes request servicing logic 150that can be implemented using the processing resources 138, memoryresources 142 and other computing system resources 146. Requestservicing logic 150 is illustratively the logic that makes up theservice being hosted, so that logic 150 receives web service requeststhat are sent to it from system 118 and processes those requests andgenerates responses to those requests. The responses can be sent back tothe requesting client computing system 104-106 through a communicationcomponent that communicates over network 108, or through any othercomputing system functionality 126.

FIG. 2 shows that sandboxed web service instance 124 also illustrativelyincludes request servicing logic 152. Logic 152 is illustratively thesame as logic 150 so that sandboxed web service instance 124 can servicethe same web service requests as default web service instance 122. Logic152 can be implemented using the processing resources 140, memoryresources 144 and other computing system resources 148 that are assignedto sandboxed web service instance 124.

As discussed above, the computing system resources that are assigned toeach of the instances 122-124 can be assigned by an administrator oranother person who has access to computing system 102 which will allowthat person to assign computing resources to different instances. Asalso mentioned above, the computing system resources assigned tosandboxed web service instance 124 may be significantly smaller thanthose assigned to default web service instance 122, because it iscontemplated that sandboxed web service instance 124 will likely servicefewer requests than instance 122. However, the example in which theresources assigned to instance 124 are smaller than those assigned toinstance 122 is only one example. In either case, the computing systemresources are illustratively separated from one another so that theperformance in executing web service requests in one instance 122, 124will not affect the performance in executing web service requests in theother instance 122, 124.

Request filter and router system 118 illustratively includes one or moreprocessors or servers 154, grouping system 156, sandbox instancegenerator 158, router logic 160, metric detector logic 162, and it caninclude a wide variety of other items 164. Request grouping logic 156,itself, illustratively includes group identifier logic 166, groupgenerator logic 168, group removal logic 169 and it can include otheritems 170. Router logic 160 can include metric comparison logic 172,routing control signal generator 174 (which, itself, includes defaultcontroller 178, sandbox controller 180, and can include other items182), and it can include other items 184. It will be noted thatcontrollers 178 and 180 can be the same or different controllers, as isdescribed in more detail below.

Metric detector logic 162 illustratively includes latency detector 186,request volume/frequency detector 188, CPU usage detector 190, memoryusage detector 192, queue length detector 194, metric update logic 196,and it can include other items 198.

Request-based threshold and performance metric data store 120illustratively includes grouping rules 199 that specify how requests areto be grouped (based on a set of grouping criteria), and data for aplurality of request groups 200-202. It can include other items 204 aswell. Each request group illustratively includes grouping criteria 206,metric values 208, and metric threshold values 210. Each request groupcan include other items 212 as well.

Before describing the overall operation of architecture in more detail,a brief overview of some of the items in request filter and routersystem 118, and their operation, will first be described. Sandboxinstance generator 158 illustratively includes functionality that allowsan administrator or another person to generate a sandboxed web serviceinstance 124. It allows the assignment of the various computing systemresources shown in instance 124, to the sandboxed service web instance.It can also include logic that automatically generates another sandboxedweb service instance 124 and assigns resources to it, or assignsadditional resources to instance 124, when needed. It will also be notedthat sandbox instance generator 158 can automatically generateadditional sandboxed web service instances 124 and assign resources tothem, under certain criteria. Some of those will be described in moredetail below. By automatically, it is meant that the process or stepsare performed without additional user or administrator involvement,except perhaps to initiate or authorize the process steps.

When system 118 receives a web service request over network 108,grouping system 156 accesses grouping rules 199 to determine whether thecurrently received request belongs to a request group 200-202 that isspecified by the rules. The request groups are formed based on rulesthat specify various grouping criteria 206 that can be used to identifywhich particular group a newly incoming request belongs to. The rulescan be pre-configured by a user or administrator using grouping system156, or they can be generated or updated on-the-fly. They can also beremoved by group removal logic 169. The grouping criteria can includethe type of request, the source of the request (e.g., the user, theapplication, etc.), the requested resources, or other criteria. When arequest is received, group identifier logic 166 determines whether thereis a rule that would group the request into a group and, if so, filtersthe request groups 200-202 in store 120, based on the rules and groupingcriteria, to identify the group to which the newly received requestbelongs.

An example may be helpful. Assume two grouping rules 199 have been input(by a user or otherwise) as follows:

Rule A: Group #1 into “operation”, “user Agent”

Rule B: Group #2 into “operation”, “Application”

These rules specify that all requests that have a same operation anduser agent are to be grouped together, and all requests that have thesame operation and requesting application are to be grouped together.Now assume that the following requests have been received, sequentially:

10 incoming requests have “Operation as Read”, “UserAgent asAcmeMobile”, “Application as email”

5 incoming requests have “Operation as Read”, UserAgent as AcmeDesktop”,Application as email”

20 incoming requests have “Operation as Update”, “UserAgent as Beta”,“Application as Maps”

Then, based on Rule A, a group with criteria “Read”, AcmeMobile” willhave 10 entries and the metric values for that group will be based onthe metric values for each entry in the group (e.g., an average of eachmetric taken over the entries in the group).

Also, based on Rule A, another group with criteria “Read”, “AcmeDesktop”will have 5 entries with metric values based on those entries. Yetanother group with criteria “update”, “Beta” will have 20 entries withcorresponding metric values.

Based on Rule B, a group with criteria “Read”, “Email” will have 15entries. Another group with criteria “Update”, “Maps” will have 20entries.

If group identifier logic 166 determines that there are no rules 199specifying a group for the newly received request, as is describedbelow, metric detector logic 162 then begins monitoring the variousperformance metrics during execution of that request. A group can becreated for it by modifying the grouping rules 199. It can store andupdates metric values for the request. It can also illustrativelyestablish or receive metric threshold values 210 if a group is specifiedor the metric threshold values 210 can be predefined or set by anadministrator, or otherwise set.

Also, if no group was identified for the currently received request,then router logic 160 sends the currently received request to thedefault web service instance 122 for execution. However, if it wasdetermined by group identifier logic 166 that the currently receivedrequest belongs to a request group 200-202 for which a record hasalready been generated, then metric comparison logic 172 determineswhether enough data has been collected by metric detector logic 162 forthe various metric values 208 in the identified request group to make avalid threshold comparison. If so, it compares the metric values 208that have been collected for the group to which the newly receivedrequest belongs, to the metric threshold values 210 for those metrics.If the metric values for the group exceed the threshold values 210, thencomparison logic 172 generates a comparison signal indicative of this.

Based on that signal, routing control signal generator 176 generatescontrol signals to route the request to the proper instance 122-124.When the comparison signal indicates that the comparison shows thisrequest to belong to a problematic request group, (e.g., if the CPUusage metric value meets or exceeds the CPU usage threshold value, etc.)then sandbox controller 180 generates control signals to send therequest to sandboxed web service instance 124, for execution. When thenewly received request belongs to a group that is not problematic (e.g.,the metric values 208 for the group to which the newly received requestbelongs, do not meet the metric threshold values 210) then defaultcontroller 178 generates control signals to send the newly receivedrequest to default web service instance 122. Controllers 178 and 180 canbe the same piece of logic, or they can be different.

In either case, metric detector logic 162 monitors the variousperformance metrics to obtain values corresponding to the execution ofthe newly received request. It then updates the metric values 208 in thegroup to which the newly received request belongs, once execution ofthat request has been completed. By way of example, latency detector 186monitors the request-response latency for the newly received request.Request volume/frequency detector 188 detects the number of requeststhat belong to the present group that have been received, and/or thefrequency with which they are received over a given period of time, orrelative to requests belonging to other groups. CPU usage detector 190identifies a level of CPU usage that was consumed during execution ofthe request. Memory usage detector 192 identifies a level of memory thatwas consumed during execution of the request. Queue length detector 194identifies a length of the various queues that are used in executing therequest. A wide variety of other metrics can be monitored as well. Itwill also be noted that, in one example, metric detector logic 162 canperform detection or monitoring at different levels depending on whetherthe web service request was executed in default web service instance 122or sandboxed web service instance 124. For instance, more general metricdetection can be performed when the request is executed in instance 122.However, when the request has been identified as a potentiallyproblematic request, so that it is executed in sandboxed web serviceinstance 124, then additional metrics may be detected, the metrics maybe detected at a more granular level, or other more detailed metricdetection can be performed by metric detector logic 162. These are onlyexamples.

Metric update logic 196 updates the metric values 208 in the group towhich the newly received request belongs, once that request has beenexecuted (whether it was executed by default web service instance 122 orsandboxed web service instance 124).

FIGS. 3A-3B (collectively referred to herein as FIG. 3) show one exampleof a flow diagram illustrating the operation of computing system 102 inexecuting a web service request by routing it to default web serviceinstance 122 or sandboxed web service instance 124, based upon how itscorresponding metric values compare to the metric threshold values forthe group of similar requests. FIGS. 2 and 3 will now be described inconjunction with one another.

It is first assumed that both the default web service instance 122 andthe sandboxed web service instance 124 have been created. This can bedone automatically, on-the-fly, or based on user or administratorinputs. Creating the default web service instance 122 is indicated byblock 220 in the flow diagram of FIG. 3. Creation of instance 122 willinclude assigning it the computing system resources as indicated byblock 224. The resources can include any of the resources 138, 142, 146described above, or other resources 226.

Creating the sandboxed web service instance 124 is indicated by block228 in the flow diagram of FIG. 3. As discussed above, the computingresources 140, 144, 148 assigned to the sandboxed web service instance124 may be a fraction of those assigned to the default web serviceinstance 122. This is indicated by block 230 in the flow diagram of FIG.3. Also, in one example, the computing system resources assigned toinstance 124 are not shared with those assigned to instance 122. This isindicated by block 232, and is done so that the execution of servicerequests in sandboxed web service instance 124 will not affect theperformance of executing other service requests in default web serviceinstance 122.

It may be that the computing system resources 140, 144, and 148 that areassigned to the sandboxed web service instance 124 are preconfigured.For instance, the amount of resources may be preconfigured, theparticular resources that are assigned may be preconfigured or theresources may be preconfigured in other ways as well. This is indicatedby block 234. In another example, the sandboxed web service instance 124may be created on-the-fly, as needed. For instance, sandbox instancegenerator 158 may generate and/or delete additional sandboxed webservice instances 124 as they are needed, based upon the number ofrequests being sent to the sandboxed web service instances 124 that arealready created. Creating and/or deleting them on-the-fly is indicatedby block 236 in the flow diagram of FIG. 3. The sandboxed web serviceinstance 124 can be created in other ways as well, and this is indicatedby block 238.

If they are not already received, grouping rules 199 are then receivedand group generator logic 168 creates records in the data store 120 forthe request groups 200-202 defined by rules 199. This can be doneon-the-fly, as requests are received as well. Receiving the groupingrules 199 and generating the records for the request groups areindicated by blocks 237 and 239, respectively.

Request filter and router system 118 then receives an incoming servicerequest from a client computing system (e.g., from system 104). This isindicated by block 240 in the flow diagram of FIG. 3. In one example,the request will be a service request, from a web application, that isto be executed by a service instance on computing system 102.

Grouping system 156 then accesses grouping rules 199 and applies thegrouping criteria (e.g., grouping criteria in rules 199 that definegroups) to determine whether the newly received request belongs to oneof the request groups 200-202 that have been generated in data store120. This is indicated by block 242 in the flow diagram of FIG. 3.

The grouping criteria in the grouping rules 199, that define the requestgroups 200-202, can take a wide variety of different forms. Forinstance, they can include the type of request 244. The service requestmay be, for instance, a SOAP call, it can have an action name, it can bea particular method call, it can identify a particular action that is tobe taken or executed, or it can include a wide variety of otheridentifiers that identify the type of request.

The grouping criteria can also include the request source 246. By way ofexample, the source of the request may be identified by a user ID thatidentifies the particular user that initiated the request. It can be anapplication identifier that identifies the application (e.g., the clientapplication or other application) that initiated the request. Therequest source can be identified in other ways as well.

The grouping criteria can include an identifier that identifies therequested resources. This is indicated by block 248. For instance, whena request requests a specific resource or type of resource, or requeststhat a particular action be taken on a particular resource, then thismay be grouped with other requests that request the same resources. Thegrouping criteria can include a wide variety of other criteria as well,and this is indicated by block 250.

Group identifier logic 166 then determines, by applying the criteria inthe different rules 199 to the newly received service request, whether agroup exists for this service request. For instance, it identifies theparticular grouping criteria for the various request rules 199 thatdefine groups 200-202 and determines whether the current service requesthas criteria that match up with the grouping criteria in the rules (thatdefine the particular request groups). Determining whether the currentrequest belongs to a group that already exists in data store 120 isindicated by block 252. If not, processing then reverts to block 256where router logic 160 uses default controller 178 to generate controlsignals that route the currently received service request to default webservice instance 122. The request servicing logic 150 in default webservice instance 122 then uses the various computing system resources138, 142 and 146, that have been assigned to instance 122, to executethe web service request.

If, at block 252, it is determined that the present web service requestdoes belong to a request group 200-202 that has already been created,then group identifier logic 166 identifies the matching group (therequest group 200-202) that has grouping criteria 206 that match thenewly received web service request. Identifying the matching group isindicated by block 258 in the flow diagram of FIG. 3.

Metric comparison logic 172 then determines whether the particularrequest group that was identified by group identifier logic 166 (thegroup to which the newly received web service request belongs) hassufficient samples for the metric values 208 to do a thresholdcomparison. Determining whether sufficient samples exist is indicated byblock 260. The number of examples that are sufficient in order to do athreshold comparison may be predefined. It may also be defineddynamically or on-the-fly. Also, the number of samples that are neededmay vary depending on the request group to which the current requestbelongs. For example, it may vary based on the type of request or basedon any of the other grouping criteria. The number of samples needed mayvary in other ways as well.

If there are not a sufficient number of samples for the metric values208, then processing again reverts to block 256 where the request isrouted to the default web service instance 122 for execution. The metricvalues are then monitored and stored in data store 120, as is describedbelow.

If, at block 260, it is determined that a sufficient number of samplesfor the identified request group do exist in data store 120, then metriccomparison logic 172 compares the metric values 208 for the requestgroup 200 to which the present request belongs, to the metric thresholdvalues 210 for those metrics. This is indicated by block 262 in the flowdiagram of FIG. 3. Again, the particular metrics that are tracked, andthat have threshold values can vary widely. They can include, forinstance, the request-response latency 264. They can include the requestvolume or frequency 266. They can include the level of CPU usage 268,the level of memory usage 270, the length of the request queues 272, orthey can include a wide variety of other metrics 274. Again, thethreshold values can be predefined, they can vary dynamically, they canchange based upon the particular metric being compared, or they can beestablished in other ways as well.

Metric comparison logic 172 then generates a comparison signalindicative of the comparison, and thus indicative of whether the requestshould be sandboxed. This is indicated by block 274 and can be done in awide variety of ways. For instance, it may be that if a single metricvalue meets its corresponding threshold value, this is enough to triggera yes response at block 274. It may be that more than one metric valueneeds to meet the threshold value. It may be that certain metric valuesare weighted higher than other metric values in doing the comparison.All of these and other comparison techniques are contemplated herein.Regardless of the comparison technique, it will be assumed that, if themetric values meet or exceed the threshold values, then this indicatesthat the newly received web request belongs to a request group that hasexhibited problematic performance, or performance that may affect theperformance of other web service requests that belong to other requestgroups, or another type of performance that indicates that the newlyreceived web service request should be sandboxed during its execution.Thus, sandbox controller 180 then generates control signals to routethis web service request to sandboxed web service instance 124. This isindicated by block 276. Request servicing logic 152 then uses thevarious computing resources 140, 144 and 148 that have been assigned tothe sandboxed instance 124 in order to execute the web service requestand respond to it.

If, at block 274, metric comparison logic 172 determines that the metricvalues, for the request group to which the newly received web requestbelongs, do not meet their threshold values, then processing againcontinues at block 256 where default controller 178 generates controlsignals to route this request to the default web service instance 122where it will be executed and respond to. Again, controllers 178 and 180may be a single routing controller that routes the request to thedifferent instances, or they can be different controllers.

Regardless of whether the web service request is executed in the defaultweb service instance 122 or the sandboxed web service instance 124,metric detector logic 162 detects values for the various metrics thatare being monitored for this request group, and updates the metricvalues 208 in data store 120, with the new sample of metric valuesobtained for the newly received web request. Tracking the metric valuesfor the newly received web service request, as it is being executed, isindicated by block 278 in the flow diagram of FIG. 3. The monitoringmechanisms used by metric detector logic 162 may be the same forrequests executed in instance 122 and those executed by instance 124, orthey may be different based upon the particular instance where therequest is executed. For example, the monitoring mechanisms may be morefine-grained or otherwise different when the request is executed in thesandboxed instance 124 than when it is executed in the default instance122. This is indicated by block 280.

Also, the particular metric values that are tracked may vary widely,based upon the request, or based upon a wide variety of other criteria.As discussed above with respect to block 262, they can include therequest-response latency 282 (as detected by latency detector 186), therequest volume/frequency 284 (as detected by request volume/frequencydetector 188), the level of CPU usage 286 (as detected by CPU usagedetector 190), the level of memory usage 288 (as detected by memoryusage detector 192), the request queue length 290 (as detected by queuelength detector 194), or they can include a wide variety of othermetrics 292.

Once the new samples for the various metrics have been obtained for theexecution of the newly received web service request, metric update logic196 updates the particular metric values 208 in data store 120 for theidentified request group. This is indicated by block 292. By way ofexample, it may be that metric update logic 196 calculates a rollingaverage for each of the metric values 208 in the request group 200 (towhich the web service request that was just executed belongs). It may bethat it keeps a median value, an average value, or another value foreach of the metrics. Also, it may be that metric update logic 196 justupdates the metrics values 208, themselves. This is indicated by block294. However, it may also update the metric threshold values 210. By wayof example, if the request group to which the present request belongs isa relatively new request group, then metric update logic 196 may updatean expected level for the metric threshold value based upon the currentsample value. In another example, the threshold values are updatedmanually. In yet another example, the thresholds are set using a machinelearning system and can be intermittently updated off line oron-the-fly, by re-training based on past performance data. Updating themetric values can be done in a wide variety of different ways as well.This is indicated by block 298.

It can thus be seen that the present discussion provides an improvementin the operation of the computing system itself. It automaticallyidentifies similar types of web service requests and groups themtogether, and then monitors their performance. If certain groups ofrequests are identified as being problematic, they are automaticallyrouted to a sandboxed instance of the web service where they areexecuted. Their execution in the sandboxed instance will not affect theexecution of the other web service requests that are executed in thedefault instance. Thus, the present system automatically isolatescertain types of web service requests that can be problematic, andautomatically executes them in a sandboxed environment where they cannotdegrade the performance of the system in responding to other web servicerequests.

It will be noted that the above discussion has described a variety ofdifferent systems, components and/or logic. It will be appreciated thatsuch systems, components and/or logic can be comprised of hardware items(such as processors and associated memory, or other processingcomponents, some of which are described below) that perform thefunctions associated with those systems, components and/or logic. Inaddition, the systems, components and/or logic can be comprised ofsoftware that is loaded into a memory and is subsequently executed by aprocessor or server, or other computing component, as described below.The systems, components and/or logic can also be comprised of differentcombinations of hardware, software, firmware, etc., some examples ofwhich are described below. These are only some examples of differentstructures that can be used to form the systems, components and/or logicdescribed above. Other structures can be used as well.

The present discussion has mentioned processors and servers. In oneembodiment, the processors and servers include computer processors withassociated memory and timing circuitry, not separately shown. They arefunctional parts of the systems or devices to which they belong and areactivated by, and facilitate the functionality of the other componentsor items in those systems.

Also, a number of user interface displays have been discussed. They cantake a wide variety of different forms and can have a wide variety ofdifferent user actuatable input mechanisms disposed thereon. Forinstance, the user actuatable input mechanisms can be text boxes, checkboxes, icons, links, drop-down menus, search boxes, etc. They can alsobe actuated in a wide variety of different ways. For instance, they canbe actuated using a point and click device (such as a track ball ormouse). They can be actuated using hardware buttons, switches, ajoystick or keyboard, thumb switches or thumb pads, etc. They can alsobe actuated using a virtual keyboard or other virtual actuators. Inaddition, where the screen on which they are displayed is a touchsensitive screen, they can be actuated using touch gestures. Also, wherethe device that displays them has speech recognition components, theycan be actuated using speech commands

A number of data stores have also been discussed. It will be noted theycan each be broken into multiple data stores. All can be local to thesystems accessing them, all can be remote, or some can be local whileothers are remote. All of these configurations are contemplated herein.

Also, the figures show a number of blocks with functionality ascribed toeach block. It will be noted that fewer blocks can be used so thefunctionality is performed by fewer components. Also, more blocks can beused with the functionality distributed among more components.

FIG. 4 is a block diagram of architecture 100, shown in FIG. 1, exceptthat its elements are disposed in a cloud computing architecture 500.Cloud computing provides computation, software, data access, and storageservices that do not require end-user knowledge of the physical locationor configuration of the system that delivers the services. In variousembodiments, cloud computing delivers the services over a wide areanetwork, such as the internet, using appropriate protocols. Forinstance, cloud computing providers deliver applications over a widearea network and they can be accessed through a web browser or any othercomputing component. Software or components of architecture 100 as wellas the corresponding data, can be stored on servers at a remotelocation. The computing resources in a cloud computing environment canbe consolidated at a remote data center location or they can bedispersed. Cloud computing infrastructures can deliver services throughshared data centers, even though they appear as a single point of accessfor the user. Thus, the components and functions described herein can beprovided from a service provider at a remote location using a cloudcomputing architecture. Alternatively, they can be provided from aconventional server, or they can be installed on client devicesdirectly, or in other ways.

The description is intended to include both public cloud computing andprivate cloud computing. Cloud computing (both public and private)provides substantially seamless pooling of resources, as well as areduced need to manage and configure underlying hardware infrastructure.

A public cloud is managed by a vendor and typically supports multipleconsumers using the same infrastructure. Also, a public cloud, asopposed to a private cloud, can free up the end users from managing thehardware. A private cloud may be managed by the organization itself andthe infrastructure is typically not shared with other organizations. Theorganization still maintains the hardware to some extent, such asinstallations and repairs, etc.

In the example shown in FIG. 4, some items are similar to those shown inFIG. 1 and they are similarly numbered. FIG. 4 specifically shows thatcomputing system 102 can be located in cloud 502 (which can be public,private, or a combination where portions are public while others areprivate). Therefore, users 114-116 use user devices 504-506 to accessthose systems through cloud 502.

FIG. 4 also depicts another example of a cloud architecture. FIG. 4shows that it is also contemplated that some elements of computingsystem 102 can be disposed in cloud 502 while others are not. By way ofexample, data store 120 can be disposed outside of cloud 502, andaccessed through cloud 502. In another example, request filter androuting system 118 (or other items) can be outside of cloud 502.Regardless of where they are located, they can be accessed directly bydevices 504-506, through a network (either a wide area network or alocal area network), they can be hosted at a remote site by a service,or they can be provided as a service through a cloud or accessed by aconnection service that resides in the cloud. All of these architecturesare contemplated herein.

It will also be noted that architecture 100, or portions of it, can bedisposed on a wide variety of different devices. Some of those devicesinclude servers, desktop computers, laptop computers, tablet computers,or other mobile devices, such as palm top computers, cell phones, smartphones, multimedia players, personal digital assistants, etc.

FIG. 5 is one example of a computing environment in which architecture100, or parts of it, (for example) can be deployed. With reference toFIG. 5, an example system for implementing some embodiments includes ageneral-purpose computing device in the form of a computer 810.Components of computer 810 may include, but are not limited to, aprocessing unit 820 (which can comprise processors or servers fromprevious FIGS.), a system memory 830, and a system bus 821 that couplesvarious system components including the system memory to the processingunit 820. The system bus 821 may be any of several types of busstructures including a memory bus or memory controller, a peripheralbus, and a local bus using any of a variety of bus architectures. By wayof example, and not limitation, such architectures include IndustryStandard Architecture (ISA) bus, Micro Channel Architecture (MCA) bus,Enhanced ISA (EISA) bus, Video Electronics Standards Association (VESA)local bus, and Peripheral Component Interconnect (PCI) bus also known asMezzanine bus. Memory and programs described with respect to FIG. 1 canbe deployed in corresponding portions of FIG. 5.

Computer 810 typically includes a variety of computer readable media.Computer readable media can be any available media that can be accessedby computer 810 and includes both volatile and nonvolatile media,removable and non-removable media. By way of example, and notlimitation, computer readable media may comprise computer storage mediaand communication media. Computer storage media is different from, anddoes not include, a modulated data signal or carrier wave. It includeshardware storage media including both volatile and nonvolatile,removable and non-removable media implemented in any method ortechnology for storage of information such as computer readableinstructions, data structures, program modules or other data. Computerstorage media includes, but is not limited to, RAM, ROM, EEPROM, flashmemory or other memory technology, CD-ROM, digital versatile disks (DVD)or other optical disk storage, magnetic cassettes, magnetic tape,magnetic disk storage or other magnetic storage devices, or any othermedium which can be used to store the desired information and which canbe accessed by computer 810. Communication media typically embodiescomputer readable instructions, data structures, program modules orother data in a transport mechanism and includes any informationdelivery media. The term “modulated data signal” means a signal that hasone or more of its characteristics set or changed in such a manner as toencode information in the signal. By way of example, and not limitation,communication media includes wired media such as a wired network ordirect-wired connection, and wireless media such as acoustic, RF,infrared and other wireless media. Combinations of any of the aboveshould also be included within the scope of computer readable media.

The system memory 830 includes computer storage media in the form ofvolatile and/or nonvolatile memory such as read only memory (ROM) 831and random access memory (RAM) 832. A basic input/output system 833(BIOS), containing the basic routines that help to transfer informationbetween elements within computer 810, such as during start- up, istypically stored in ROM 831. RAM 832 typically contains data and/orprogram modules that are immediately accessible to and/or presentlybeing operated on by processing unit 820. By way of example, and notlimitation, FIG. 5 illustrates operating system 834, applicationprograms 835, other program modules 836, and program data 837.

The computer 810 may also include other removable/non-removablevolatile/nonvolatile computer storage media. By way of example only,FIG. 5 illustrates a hard disk drive 841 that reads from or writes tonon-removable, nonvolatile magnetic media, and an optical disk drive 855that reads from or writes to a removable, nonvolatile optical disk 856such as a CD ROM or other optical media. Other removable/non-removable,volatile/nonvolatile computer storage media that can be used in theexemplary operating environment include, but are not limited to,magnetic tape cassettes, flash memory cards, digital versatile disks,digital video tape, solid state RAM, solid state ROM, and the like. Thehard disk drive 841 is typically connected to the system bus 821 througha non-removable memory interface such as interface 840, and optical diskdrive 855 are typically connected to the system bus 821 by a removablememory interface, such as interface 850.

Alternatively, or in addition, the functionality described herein can beperformed, at least in part, by one or more hardware logic components.For example, and without limitation, illustrative types of hardwarelogic components that can be used include Field-programmable Gate Arrays(FPGAs), Program-specific Integrated Circuits (ASICs), Program-specificStandard Products (ASSPs), System-on-a-chip systems (SOCs), ComplexProgrammable Logic Devices (CPLDs), etc.

The drives and their associated computer storage media discussed aboveand illustrated in FIG. 5, provide storage of computer readableinstructions, data structures, program modules and other data for thecomputer 810. In FIG. 5, for example, hard disk drive 841 is illustratedas storing operating system 844, application programs 845, other programmodules 846, and program data 847. Note that these components can eitherbe the same as or different from operating system 834, applicationprograms 835, other program modules 836, and program data 837. Operatingsystem 844, application programs 845, other program modules 846, andprogram data 847 are given different numbers here to illustrate that, ata minimum, they are different copies.

A user may enter commands and information into the computer 810 throughinput devices such as a keyboard 862, a microphone 863, and a pointingdevice 861, such as a mouse, trackball or touch pad. Other input devices(not shown) may include a joystick, game pad, satellite dish, scanner,or the like. These and other input devices are often connected to theprocessing unit 820 through a user input interface 860 that is coupledto the system bus, but may be connected by other interface and busstructures, such as a parallel port, game port or a universal serial bus(USB). A visual display 891 or other type of display device is alsoconnected to the system bus 821 via an interface, such as a videointerface 890. In addition to the monitor, computers may also includeother peripheral output devices such as speakers 897 and printer 896,which may be connected through an output peripheral interface 895.

The computer 810 is operated in a networked environment using logicalconnections to one or more remote computers, such as a remote computer880. The remote computer 880 may be a personal computer, a hand-helddevice, a server, a router, a network PC, a peer device or other commonnetwork node, and typically includes many or all of the elementsdescribed above relative to the computer 810. The logical connectionsdepicted in FIG. 5 include a local area network (LAN) 871 and a widearea network (WAN) 873, but may also include other networks. Suchnetworking environments are commonplace in offices, enterprise-widecomputer networks, intranets and the Internet.

When used in a LAN networking environment, the computer 810 is connectedto the LAN 871 through a network interface or adapter 870. When used ina WAN networking environment, the computer 810 typically includes amodem 872 or other means for establishing communications over the WAN873, such as the Internet. The modem 872, which may be internal orexternal, may be connected to the system bus 821 via the user inputinterface 860, or other appropriate mechanism. In a networkedenvironment, program modules depicted relative to the computer 810, orportions thereof, may be stored in the remote memory storage device. Byway of example, and not limitation, FIG. 5 illustrates remoteapplication programs 885 as residing on remote computer 880. It will beappreciated that the network connections shown are exemplary and othermeans of establishing a communications link between the computers may beused.

It should also be noted that the different examples described herein canbe combined in different ways. That is, parts of one or more examplescan be combined with parts of one or more other examples. All of this iscontemplated herein.

Example 1 is a computing system, comprising:

request group identifier logic that receives a service request for a webservice and identifies a request group, of a plurality of differentrequest groups, to which the service request belongs, based on a set ofgrouping criteria;

metric comparison logic that compares a performance metric valuecorresponding to the identified request group to a metric thresholdvalue and that generates a comparison signal indicative of a result ofthe comparison; and

a routing controller that generates a default instance control signal tosend the service request to a first web service instance for executionwhen the comparison signal has a first value, the first web serviceinstance having a first set of assigned computing system resources thatimplement request servicing logic configured to respond to the servicerequest, and that generates a sandbox instance control signal to sendthe service request to a second web service instance for execution whenthe comparison signal has a second value, the second web serviceinstance having a second set of assigned computing system resources thatis different from, and smaller than, the first set of assigned computingsystem resources, the second set of assigned computing system resourcesimplementing the request servicing logic that is configured to respondto the service request.

Example 2 is the computing system of any or all previous examples andfurther comprising:

metric detector logic configured to detect a value of the performancemetric corresponding to execution of the service request.

Example 3 is the computing system of any or all previous exampleswherein the metric detector logic comprises:

metric update logic configured to update the performance metric valuecorresponding to the identified request group based on the detectedvalue of the performance metric corresponding to execution of theservice request.

Example 4 is the computing system of any or all previous exampleswherein the metric comparison logic is configured to compare a pluralityof different performance metric values corresponding to the identifiedrequest group to a plurality of different, corresponding metricthreshold values and generate the comparison signal based on results ofthe comparisons.

Example 5 is the computing system of any or all previous exampleswherein the metric detector logic comprises a plurality of differentmetric detectors each configured to detect a different one of theplurality of different performance metric values corresponding toexecution of the service request.

Example 6 is the computing system of any or all previous exampleswherein the metric update logic is configured to update the plurality ofdifferent performance metric values corresponding to the identifiedrequest group based on the plurality of different detected performancemetric values corresponding to execution of the service request.

Example 7 is the computing system of any or all previous examples andfurther comprising the first and second web service instances, whereinthe first and second sets of assigned computing system resources areconfigured so that execution of the service request, that operates on afirst portion of data, on the first web service instance is unaffectedby execution of another service request, that operates on a differentportion of data, on the second web service instance.

Example 8 is the computing system of any or all previous examples andfurther comprising:

a sandbox instance generator configured to automatically generateadditional web service instances, each with an additional set ofassigned computing system resources that is different from, and smallerthan, the first set of computing system resources.

Example 9 is the computing system of any or all previous examples andfurther comprising:

request grouping logic configured to access a set of grouping rules andgenerate the plurality of different request groups by applying thegrouping criteria in each of the grouping rules to received servicerequests to identify sets of similar service requests based on thegrouping criteria and generating a request group for each set of similarservice requests.

Example 10 is the computing system of any or all previous exampleswherein the request grouping logic is configured to generate anadditional grouping rule that defines an additional request group whenthe request group identifier logic identifies that a service request isreceived that does not belong to a request group, based on the groupingcriteria.

Example 11 is a computer implemented method, comprising:

receiving a service request for a web service;

identifying a request group, of a plurality of different request groups,to which the service request belongs, based on a set of groupingcriteria;

comparing a performance metric value corresponding to the identifiedrequest group to a metric threshold value and generating a comparisonsignal indicative of a result of the comparison;

generating a default instance control signal to send the service requestto a first web service instance for execution when the comparison signalhas a first value, the first web service instance having a first set ofassigned computing system resources that implement request servicinglogic configured to respond to the service request; and

generating a sandbox instance control signal to send the service requestto a second web service instance for execution when the comparisonsignal has a second value, the second web service instance having asecond set of assigned computing system resources that is differentfrom, and smaller than, the first set of assigned computing systemresources, the second set of assigned computing system resourcesimplementing the request servicing logic that is configured to respondto the service request.

Example 12 is the computer implemented method of any or all previousexamples and further comprising:

detecting a value of the performance metric corresponding to executionof the service request; and

updating the performance metric value corresponding to the identifiedrequest group based on the detected value of the performance metriccorresponding to execution of the service request.

Example 13 is the computer implemented method of any or all previousexamples wherein comparing comprises:

comparing a plurality of different performance metric valuescorresponding to the identified request group to a plurality ofdifferent, corresponding metric threshold values and wherein generatingthe comparison signal comprises generating the comparison signal basedon results of the comparisons.

Example 14 is the computer implemented method of any or all previousexamples wherein detecting a value of the performance metric comprisesdetecting a plurality of different performance metric valuescorresponding to execution of the service request and wherein updatingthe performance metric value corresponding to the identified requestgroup comprises updating a plurality of different performance metricvalues corresponding to the identified request group based on theplurality of different detected performance metric values correspondingto execution of the service request.

Example 15 is the computer implemented method of any or all previousexamples and further comprising:

automatically generating additional web service instances, each with anadditional set of assigned computing system resources that is differentfrom, and smaller than, the first set of computing system resources.

Example 16 is the computer implemented method of any or all previousexamples and further comprising:

automatically generating the plurality of different request groups byapplying the grouping criteria to received service requests to identifysets of similar service requests based on the grouping criteria andgenerating a request group for each set of similar service requests.

Example 17 is a computing system, comprising:

a first web service instance having a first set of assigned computingsystem resources that implement request servicing logic configured torespond to web service requests;

a second web service instance having a second set of assigned computingsystem resources that is different from, and smaller than, the first setof assigned computing system resources, the second set of assignedcomputing system resources implementing the request servicing logic thatis configured to respond to the service requests;

request group identifier logic that receives a service request andidentifies a request group, of a plurality of different request groups,to which the service request belongs, based on a set of groupingcriteria;

metric comparison logic that compares a performance metric valuecorresponding to the identified request group to a metric thresholdvalue and that generates a comparison signal indicative of a result ofthe comparison; and

a controller that generates a default instance control signal to sendthe service request to the first web service instance for execution whenthe comparison signal has a first value, and that generates a sandboxinstance control signal to send the service request to the second webservice instance for execution when the comparison signal has a secondvalue.

Example 18 is the computing system of any or all previous exampleswherein the first and second sets of assigned computing system resourcesare configured so that execution of the service request on the first webservice instance is unaffected by execution of another service request,that operates on different data, on the second web service instance.

Example 19 is the computing system of any or all previous examples andfurther comprising:

a sandbox instance generator configured to automatically generateadditional web service instances, each with an additional set ofassigned computing system resources that is different from, and smallerthan, the first set of computing system resources.

Example 20 is the computing system of any or all previous examples andfurther comprising:

metric detector logic configured to detect a value of the performancemetric corresponding to execution of the service request; and

metric update logic configured to update the performance metric valuecorresponding to the identified request group based on the detectedvalue of the performance metric corresponding to execution of theservice request.

Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the specific features or acts described above.Rather, the specific features and acts described above are disclosed asexample forms of implementing the claims.

What is claimed is:
 1. A computing system, comprising: request groupidentifier logic that receives a service request for a web service andidentifies a request group, of a plurality of different request groups,to which the service request belongs, based on a set of groupingcriteria; metric comparison logic that compares a performance metricvalue corresponding to the identified request group to a metricthreshold value and that generates a comparison signal indicative of aresult of the comparison; and a routing controller that generates adefault instance control signal to send the service request to a firstweb service instance for execution when the comparison signal has afirst value, the first web service instance having a first set ofassigned computing system resources that implement request servicinglogic configured to respond to the service request, and that generates asandbox instance control signal to send the service request to a secondweb service instance for execution when the comparison signal has asecond value, the second web service instance having a second set ofassigned computing system resources that is different from, and smallerthan, the first set of assigned computing system resources, the secondset of assigned computing system resources implementing the requestservicing logic that is configured to respond to the service request. 2.The computing system of claim 1 and further comprising: metric detectorlogic configured to detect a value of the performance metriccorresponding to execution of the service request.
 3. The computingsystem of claim 2 wherein the metric detector logic comprises: metricupdate logic configured to update the performance metric valuecorresponding to the identified request group based on the detectedvalue of the performance metric corresponding to execution of theservice request.
 4. The computing system of claim 1 wherein the metriccomparison logic is configured to compare a plurality of differentperformance metric values corresponding to the identified request groupto a plurality of different, corresponding metric threshold values andgenerate the comparison signal based on results of the comparisons. 5.The computing system of claim 4 wherein the metric detector logiccomprises a plurality of different metric detectors each configured todetect a different one of the plurality of different performance metricvalues corresponding to execution of the service request.
 6. Thecomputing system of claim 5 wherein the metric update logic isconfigured to update the plurality of different performance metricvalues corresponding to the identified request group based on theplurality of different detected performance metric values correspondingto execution of the service request.
 7. The computing system of claim 3and further comprising the first and second web service instances,wherein the first and second sets of assigned computing system resourcesare configured so that execution of the service request, that operateson a first portion of data, on the first web service instance isunaffected by execution of another service request, that operates on adifferent portion of data, on the second web service instance.
 8. Thecomputing system of claim 3 and further comprising: a sandbox instancegenerator configured to automatically generate additional web serviceinstances, each with an additional set of assigned computing systemresources that is different from, and smaller than, the first set ofcomputing system resources.
 9. The computing system of claim 3 andfurther comprising: request grouping logic configured to access a set ofgrouping rules and generate the plurality of different request groups byapplying the grouping criteria in each of the grouping rules to receivedservice requests to identify sets of similar service requests based onthe grouping criteria and generating a request group for each set ofsimilar service requests.
 10. The computing system of claim 9 whereinthe request grouping logic is configured to generate an additionalgrouping rule that defines an additional request group when the requestgroup identifier logic identifies that a service request is receivedthat does not belong to a request group, based on the grouping criteria.11. A computer implemented method, comprising: receiving a servicerequest for a web service; identifying a request group, of a pluralityof different request groups, to which the service request belongs, basedon a set of grouping criteria; comparing a performance metric valuecorresponding to the identified request group to a metric thresholdvalue and generating a comparison signal indicative of a result of thecomparison; generating a default instance control signal to send theservice request to a first web service instance for execution when thecomparison signal has a first value, the first web service instancehaving a first set of assigned computing system resources that implementrequest servicing logic configured to respond to the service request;and generating a sandbox instance control signal to send the servicerequest to a second web service instance for execution when thecomparison signal has a second value, the second web service instancehaving a second set of assigned computing system resources that isdifferent from, and smaller than, the first set of assigned computingsystem resources, the second set of assigned computing system resourcesimplementing the request servicing logic that is configured to respondto the service request.
 12. The computer implemented method of claim 11and further comprising: detecting a value of the performance metriccorresponding to execution of the service request; and updating theperformance metric value corresponding to the identified request groupbased on the detected value of the performance metric corresponding toexecution of the service request.
 13. The computer implemented method ofclaim 12 wherein comparing comprises: comparing a plurality of differentperformance metric values corresponding to the identified request groupto a plurality of different, corresponding metric threshold values andwherein generating the comparison signal comprises generating thecomparison signal based on results of the comparisons.
 14. The computerimplemented method of claim 13 wherein detecting a value of theperformance metric comprises detecting a plurality of differentperformance metric values corresponding to execution of the servicerequest and wherein updating the performance metric value correspondingto the identified request group comprises updating a plurality ofdifferent performance metric values corresponding to the identifiedrequest group based on the plurality of different detected performancemetric values corresponding to execution of the service request.
 15. Thecomputer implemented method of claim 12 and further comprising:automatically generating additional web service instances, each with anadditional set of assigned computing system resources that is differentfrom, and smaller than, the first set of computing system resources. 16.The computer implemented method of claim 12 and further comprising:automatically generating the plurality of different request groups byapplying the grouping criteria to received service requests to identifysets of similar service requests based on the grouping criteria andgenerating a request group for each set of similar service requests. 17.A computing system, comprising: a first web service instance having afirst set of assigned computing system resources that implement requestservicing logic configured to respond to web service requests; a secondweb service instance having a second set of assigned computing systemresources that is different from, and smaller than, the first set ofassigned computing system resources, the second set of assignedcomputing system resources implementing the request servicing logic thatis configured to respond to the service requests; request groupidentifier logic that receives a service request and identifies arequest group, of a plurality of different request groups, to which theservice request belongs, based on a set of grouping criteria; metriccomparison logic that compares a performance metric value correspondingto the identified request group to a metric threshold value and thatgenerates a comparison signal indicative of a result of the comparison;and a controller that generates a default instance control signal tosend the service request to the first web service instance for executionwhen the comparison signal has a first value, and that generates asandbox instance control signal to send the service request to thesecond web service instance for execution when the comparison signal hasa second value.
 18. The computing system of claim 17 wherein the firstand second sets of assigned computing system resources are configured sothat execution of the service request on the first web service instanceis unaffected by execution of another service request, that operates ondifferent data, on the second web service instance.
 19. The computingsystem of claim 18 and further comprising: a sandbox instance generatorconfigured to automatically generate additional web service instances,each with an additional set of assigned computing system resources thatis different from, and smaller than, the first set of computing systemresources.
 20. The computing system of claim 19 and further comprising:metric detector logic configured to detect a value of the performancemetric corresponding to execution of the service request; and metricupdate logic configured to update the performance metric valuecorresponding to the identified request group based on the detectedvalue of the performance metric corresponding to execution of theservice request.